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© Uniform interface for cryptographic services. 



© A security kernel (6) of a secure processing 
system for providing security management, key 
management and kernel security functions. The se- 
cure processing system includes two parallel sub- 
systems, a red subsystem (7) and a black sub- 
system (8). The red subsystem (7) may commu- 
nicate only with the kernel (6) since this system 
transfers plain text data. The black subsystem (8) 
may communicate with the red subsystem (7) and 



also other processing systems for the transmission 
of cypher text data. The security kernel (6) is a 
single standard interface for tasks associated with 
the red (7) and black (8) subsystems for commu- 
nicating in a secure manner with one another and 
with other processing systems. Various security ser- 
vices are provided to red (7) and black (8) sub- 
system applications by a single security kernel (6). 
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UNIFORM INTERFACE FOR CRYPTOGRAPHIC SERVICES 



Background of the invention 



The present invention pertains to computer and 
communication systems and more particularly a 
security kernel interface for simplifying the integra- 
tion of cryptographic services to computer or com- 
munication systems. 

Typically, communication systems are con- 
trolled by a central processing unit (CPU). The 
CPU controls the flow of data within the system. 
Further, the CPU controls the flow of data into the 
system and the data flow out from the system. 
Such CPU controlled systems are very useful in 
establishing high speed communications with other 
CPU controlled systems. Since such systems now 
have the ability to directly communicate, data secu- 
rity problems have arisen. 

As a result of the communication between sys- 
tems, it is necessary to control the access of data 
between secure distributed systems. Secure data 
may include a company's proprietary information, 
banking or financial type data, and government 
classified data. To provide for data security, sys- 
tems have included interfaces for establishing 
passwords to allow access to certain data and have 
encoded secure data when it is transmitted be- 
tween systems. Also, these systems typically em- 
ploy key management to control access of the 
system by users. Heretofore, these cryptographic 
services, key management and secure system 
management services were provided separately. 
Sometimes these functions were provided by hard- 
ware and other times by software. Each one of the 
above-mentioned services was typically an isolated 
event. That is, if one desired to have a cryp- 
tographic service performed, the cryptographic 
module was given control. If one desired key man- 
agement, the key management module was given 
control, etc. 

Accordingly, it is an object of the present in- 
vention to provide a uniform system interface for 
cryptographic services, key management services 
and secure system management services in a se- 
curity kernel. 

Summary of the Invention 



In accomplishing the object of the present in- 
vention, a novel and uniform interface for cryp- 
tographic services, key management services, and 
secure system management services will be 
shown. 

A security kernel of a secure processing sys- 
tem provides cryptographic, key management and 
system security management services in a single 



security kernel. The secure processing system in- 
cludes a processor for the execution of tasks, a red 
subsystem for handling plain text data and a black 
subsystem for handling cypher text data. The secu- 

5 rity kernel includes a security management unit 
which is connected to the red and to the black 
subsystems. The security management unit pro- 
vides for rekeying converting original seed keys to 
operational keys and for determining when keys 

w are compromised. When keys are compromised a 
compromised key list is generated for use through- 
out the secure network. 

The security kernel further includes a key man- 
agement unit. The key management unit is con- 

75 nected to the security management unit, to the 
processor, and to the black and red subsystems. 
The key management unit establishes cryptograph- 
ic association between the secure processing sys- 
tem and other secure processing systems. 

20 Lastly, the security kernel includes a kernel 

security unit. The kernel security unit is connected 
to the key management unit. The security kernel 
unit operates in response to the key management 
unit to decrypt cypher text data of the black sub- 

25 system to plain text data for use by the red sub- 
system. Also, the security kernel unit encrypts 
plain text data of the red subsystem to cypher text 
data for use by the black subsystem. 

Accordingly, the present invention provides in a 

30 first aspect a security kernel of a secure process- 
ing system for providing cryptographic, key man- 
agement and system security management ser- 
vices, said secure processing system including a 
processor for the execution of tasks, a red sub- 

35 system for handling plain text data, and a black 
subsystem for handling cypher text data, said se- 
curity kernel comprising: 

means for security management connected to said 
red subsystem and to said black subsystem and to 
40 said processor, said means for security manage- 
ment operating to provide for rekeying, original to 
operational seed key conversion, and determining 
compromised keys; 

means for key management connected to said 
45 means for security management, to said processor, 
and to said red and black subsystems, said means 
for key management operating in response to said 
means for security management to establish cryp- 
tographic connection between said secure process- 
so ing system and other secure processing systems; 
and 

means for kernel security connected to said means 
for key management, said means for kernel secu- 
rity operating in response to said means for key 
management to decrypt cypher text data of said 
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black subsystem to plain text data for use by said 
red subsystem and to encrypt plain text data of 
said red subsystem to cypher text data for use by 
said black subsystem. 

In further aspects the invention provides meth- 
ods for execution in a secure processing system a 
security kernel for providing cryptographic, key 
management and system security management 
services, said secure processing system including 
a black processor system for controlling encrypted 
data and a red processor system for controlling 
unencrypted (plain text) data, said security kernel 
connected between said red processor system and 
said black processor system, namely firstly a meth- 
od for creating a cryptographic association be- 
tween an initiator and a responder comprising the 
steps of: 

requesting by said initiator the creation of a cryp- 
tographic association between said initiator and 
said responder; 

communicating between said initiator and said re- 
sponder to establish a secure data channel; 
installing said cryptographic association in said 
black processor system and in said red processor 
system of said initiator and of said requestor; and 
notifying said initiator and said responder of the 
establishment of said cryptographic association for 
the transmission of secure data; 
secondly a method for encrypting/decrypting data 
transmitted between an initiator and a responder 
comprising the steps of: 

establishing a cryptographic association between 
said initiator and said responder; 
requesting by said initiator that encrypted data be 
decrypted for transmission to said responder and 
that plain text data be encrypted for transmission to 
said responder; 

passing parameters from said initiator to said secu- 
rity kernel which indicate the location of the plain 
text data to be encrypted and the encrypted data 
to be decrypted; 

encrypting said plain text data and decrypting said 
encrypted data; and 

transmitting said encrypted/decrypted data to said 
responder; thirdly 

a method for verifying a security label of data 
comprising the steps of: 

establishing a cryptographic association including a 
security label between an initiator and a responder 
via said security kernel; 

transmitting data including a security label by an 

initiator to said security kernel; 

comparing said security label of said transmitted 

data with said security label established during said 

cryptographic association; and 

sending said data with said security label to said 

responder, if said comparison of said security label 

of said cryptographic association and said security 



label of said data successfully compare; fourthly 
a method for verifying a security label of data 
comprising the steps of: 

establishing a cryptographic association including a 
5 security label via said security kernel by an in- 
itiator; 

transmitting by an initiator a security label to said 
security kernel; 

comparing by said security kernel said security 
70 label transmitted by said initiator with a security 
label created by said cryptographic association; 
and 

indicating to said initiator whether said comparison 
of said security labels is successful or unsuccesful; 
75 fifthly 

a method for deleting an established cryptographic 
association comprising the steps of: 
determining a condition for which a particular cryp- 
tographic association is to be deleted; 
20 requesting by said security kernel said red proces- 
sor system to remove said established crypto- 
graphic association in response to said determina- 
tion of said condition; and 

requesting by said security kernel said black pro- 
25 cessor system to remove said established cryp- 
tographic association in response to said deter- 
mination of said condition; and sixthly 
a method for deleting an established cryptographic 
association comprising the steps of: 
30 first requesting by said red processor system that 
said security kernel delete an established cryp- 
tographic association; 

passing by said red processor system to said 
security kernel an identity of the particular cryp- 
35 tographic association to be deleted; 

second requesting by said security kernel that said 
red processor system delete said identified cryp- 
tographic association; and 

acknowledging by said red processor system to 
40 said security kernel that said identified crypto- 
graphic association has been deleted. 

The above and other objects, features, and 
advantages of the present invention will be better 
understood from the following detailed description 
45 taken in conjunction with the accompanying draw- 
ings. 

Brief Description of the Drawings 

so FIG. 1 is a block diagram of a secure red/black 

processor arrangement. 

FiG. 2 is a block diagram of the security kernel 
of a secure processing system of the present in- 
vention. 

55 FIG. 3 is a block diagram of the interconnec- 

tions of the security kernel and red and black 
processing systems. 

FiG. 4 is a block diagram of the initiator and 



3 



5 



EP 0 435 094 A2 



6 



responder create traffic encryption key scenarios. 

FIG. 5 is a block diagram of the initiator 
encrypt/decrypt scenarios. 

FIG. 6 is a block diagram of the local 
encrypt/decrypt scenarios. 

FIG. 7 is a block diagram of the security label 
verification scenario. 

FIG. 8 is a block diagram of the kernel initiated 
delete and the red side initiated delete scenarios. 

Description of the Preferred Embodiment 

Referring to Figure 1, a block diagram of the 
secure, red/black processor architecture is shown. 
Processor 1 is connected to direct memory access 
(DMA) units 2 and 3. DMAs 2 and 3 are connected 
to security kernel 6. DMA 2 is connected to red 
memory unit 4. DMA 3 is connected to black 
memory unit 5. 

DMA unit 2 and red memory 4 comprise the 
red memory subsystem (shown in dashed lines). 
Similarly, DMA unit 3 and black memory 5 com- 
prise the black memory subsystem (shown in 
dashed lines). 

Processor 1 is connected to red memory 4. 
Processor 1 may both read and write red memory 

4, Processor 1 is also connected to black memory 

5. Processor 1 may only read from black memory 
5. 

It is to be noted that processor 1 may not read 
red data from red memory 4 and write this data, 
inadvertently or otherwise, into black memory 5. 
Since red data is plain text, security would be 
compromised, if it were stored into black memory 
5 which contains only cypher text. By so constrain- 
ing processor 1, security of red data is maintained. 
In addition, a single control processor handles the 
data transfer. The single processor eliminates the 
extensive bussing and message transfer required 
by multiple processors. The single processor ar- 
rangement also eliminates the need for extensive 
circuitry and the physical space associated with the 
circuitry. 

Normally, data which is to be output is moved 
from the red memory 4 to the black memory 5. 
Data which is to be input to the system (not shown) 
is transferred from the black memory 5 to the red 
memory 4. 

For the outputting of data, plain text data which 
is stored in red memory 4 must be encrypted and 
stored in black memory 5 for output to another 
system. Since processor 1 cannot directly read 
data from red memory 4 and write this data into 
black memory 5, intermediate steps are used to 
achieve the data transfer. Processor 1 determines 
where the data resides in red memory 5 and the 
length of the data, assuming the data is in contig- 
uous block form. Processor 1 then instructs DMA 



unit 2 to read data from red memory 4 and gives 
DMA 2 the starting address and the length of the 
data. 

Next the plain text data from red memory 4 is 

5 passed to security kernel 6 where it is encrypted. 
The encrypted data is now cypher text data and 
may be stored into black memory 5. DMA unit 3 
receives instructions from processor 1 that the en- 
crypted data from security kernel 6 is to be stored 

w in black memory 5. Processor 1 transmits the start- 
ing address of the data and the length of the 
encrypted data, assuming the data is in a contig- 
uous block, to DMA 3. Then DMA 3 controls the 
writing of the encrypted data to black memory 5. 

15 Once the encrypted data is stored in black memory 
5, it may be safely retransmitted. At the same time 
the integrity of the system is maintained while 
being controlled by a single processor. 

Similarly for transfers of cypher text 

20 (encrypted) data to plain text data, the above pro- 
cess is reversed. Processor 1 instructs DMA 3 to 
read data from black memory 5 and gives DMA 5 
the starting address and the length of the cypher 
text data. DMA 3 reads the data from black mem- 

25 ory 5 and transfers the data to security kernel 6. 
Security kernel 6 decrypts the cypher text into 
plain text. 

Processor 1 instructs DMA 2 where to store the 
plain text data in red memory by giving DMA 2 the 

30 starting address and the length of the plain text 
data. DMA 2 then stores the piain text data, which 
is received from security kernel 6, in red memory 4 
at the appropriate place. 

Referring to FIG. 2, the details of the security 

35 kernel 6 of FIG. 1 are shown. The security kernel 6 
includes the kernel security management (KSM) 
software 20. 

The next security kernel software interface is 
the kernel management application service entity 

40 (KMASE) 30. The next software interface is the key 
management user agent (KMUA) 40. The KMUA 40 
is bi-directionally connected to both the KMASE 30 
and to the KSM 20. 

The next software module of the security ker- 

45 nel is the kernel security process (KSP) 60. The 
KSP 60 is connected to KMUA 40 and receives 
data from the KMUA 40. 

The last module of the security kernel 6 is the 
TEKMIB 70. The TEKMIB 70 is bi-directionally 

so connected between the KMUA 40 and the KSP 60. 
The TEKMIB contains traffic variables and informa- 
tion that defines usage for network 
encryption/decryption service devices. 

The kernel security management software 20 

55 controls the basic functions of the security kernel 6. 
The control functions of the KSM 20 are primarily 
to trigger the security kernel 6 to perform rekeying, 
replacing, seed key conversion and holding func- 
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tions. In addition, the KSM 20 serves as the collec- 
tion point for internal audit events and for the 
distribution of shared keys created by the security 
kernel 6. Seed key conversion is the process of 
replacing seed key material (a source key) with 
operational keying material. 

KSM 20 is bi-directionally connected to both 
the red security management 21 and the black 
security management 22 modules. The red security 
management module 21 provides interface be- 
tween KMS 20 and the system application software 
(tasks) which handles plain text data through the 
red system. The black security management mod- 
ule 22 provides interface between the KSM 20 and 
the application software (tasks) on the black sub- 
system which handles cypher text data. 

The key management application service entity 
(KMASE) 30 provides standard signaling mecha- 
nism for secured data network system (SDNS) key 
management. The secure data network system 
(SDNS) is a U.S. Government sponsored standards 
project that is used as the basis of the key man- 
agement system embodied in the present inven- 
tion. The protocol of the KMASE 30 is the key 
management protocol (KMP). The key manage- 
ment protocol is an application layer protocol re- 
sponsible for the real-time exchange of data which 
is necessary to form traffic encryption keys (TEK). 
The primary function of the key management pro- 
tocol is to provide for the establishment of a cryp- 
tographic association between various network en- 
cryption devices. This association is comprised of 
the traffic encryption key and of security attributes 
assigned to a particular TEK. 

A traffic encryption key is created from the 
exchange of credentials between network encryp- 
tion devices. Network encryption devices are sys- 
tems such as the one described in the present 
invention. These systems communicate with one 
another and must verify the level of authority of 
other systems with which it communicates. Creden- 
tials are uniquely created from the non-forgeable 
device identity assigned by the key management 
controller (KMC) 50. A traffic encryption key is 
formed by the security kernel 6 only after the 
authentication of the credentials and access control 
checks of the other communicating network en- 
cryption device. 

Traffic keys are obtained via a request from 
either the red subsystem via the red key manage- 
ment module 41 or from the black system via the 
black key management module 42. The key man- 
agement user agent (KMUA) 40 then interfaces 
with the KMASE 30 and the KMC 50 to formulate a 
traffic key. Traffic keys are temporarily stored in 
the TEKMIB 70. In addition, these traffic keys are 
relayed to the respective requesting software via 
the red or black key management modules 41 and 



42 respectively. 

The KMASE 30 may either initiate requests to 
establish traffic encryption keys to a remote net- 
work encryption device or respond to a request 

5 from a remote network encryption device for the 
generation of a traffic encryption key. If the KMASE 
30 is initiating the traffic key, it accepts service 
requests from the KMUA 40. Then the KMASE 30 
verifies the request, builds and sends a request 

ro message across the network to a remote network 
encryption device. When a response message is 
received from the remote network encryption de- 
vice, the KMASE 30 parses the message, builds 
and sends a confirmation message including a 

75 positive or negative response related to the validity 
of the inter-system communication to the KMUA 
40. 

When the KMASE 30 is the responding net- 
work encryption device, it accepts request mes- 

20 sages from a remote network encryption device. 
Then KMASE 30 parses the message and builds 
and sends a service request message to KMUA 40. 
The KMASE 30 verifies the response sent by 
KMUA 40, builds and sends a response message 

as to a remote network encryption device. 

The KMP of the KMASE 30 provides for option 
negotiation to allow for determination of the secu- 
rity attributes associated with a particular traffic 
encryption key. The security attributes that may be 

30 negotiated include the security services that a par- 
ticular traffic encryption key may provide, the secu- 
rity protocol that will use the particular traffic en- 
cryption key, the possible security labels assigned 
to protected data, and the granularity of the particu- 

35 lar traffic encryption key assignment. The particular 
traffic encryption key is used to encrypt the options 
being sent to the requesting network encryption 
device. The requesting network encryption device 
must correctly decrypt and verify the requested 

40 options before sending back an encrypted re- 
sponse. The KMP of KMASE 30 then decrypts and 
verifies the response from the remote network en- 
cryption device. The traffic encryption key is not 
valid for protection of user data traffic until the 

45 successful negotiation of all security attributes as- 
sociated with that particular key. 

The KMASE 30 also provides for the detection 
of compromised traffic encryption keys by the ex- 
change of a compromised key list with either the 

50 KMC 50 or a remote network encryption device. 

The KMASE 30 also provides for the renewal 
of identities through a interactive rekeying opera- 
tion. This rekeying operation takes place via re- 
quest to the KMUA 40. This request causes the 

55 KMASE 30 to request rekeying via the key man- 
agement controller (KMC) 50. These rekeying oper- 
ations include the conversion of seed keying ma- 
terial into operational material, new key generation 
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for compromised keys and secure data network 
system defined replacement of keying material to 
establish a new identity. 

Black presentation module 32 is connected to 
KMASE 30. Black presentation module 32 provides 
for the distribution of ciphered text data to request- 
ing application software of the black system. 

The primary purpose of the KMUA 40 is to 
provide service for key management requests from 
application programs within the system or from 
remotely located network encryption devices. Re- 
quests for key management services from remote 
network encryption devices are passed through the 
KSM 20 to KMUA 40. Requests from application 
software of this system are generally transmitted 
through red security management 21 and KSM 20 
to KMUA 40. In addition, local request may be 
transmitted from either the black key management 
42 or the red key management 41 to KMUA 40. 

One of the functions of KMUA 40 is to estab- 
lish a cryptographic association between network 
encryption devices. The KMUA 40 employs the 
association control service element (ACSE) pro- 
tocol for the establishment of the cryptographic 
association. For all key management requests, 
KMUA 40 notifies KSM 20 when the cryptographic 
association has been established. 

In order to provide service for key manage- 
ment requests within the system, KMUA 40 gen- 
erates a service request to the KMASE 30. This 
KMASE 30 service request contains all the data 
necessary for the KMASE 30 to build and to send 
to a remote network encryption device. For servic- 
ing requests from remote network encryption de- 
vices for key management, KMUA 40 first accepts 
and validates the request received by the KMASE 
30. After processing a request, KMUA 40 generates 
a response and transmits this to the KMASE 30. 
This response contains the data necessary for the 
KMASE 30 to build a response and for the KMASE 
30 to transmit this response to the remote network 
encryption device. 

KMUA 40 also manages the TEKMIB. The 
KMUA 40 monitors the crypto period of a traffic 
encryption key. When the crypto period of a traffic 
encryption key expires, KMUA 40 deletes the key 
and its attributes from the TEKMIB memory. 

Kernel security process 60 is responsible for 
the encryption and decryption functions. KSP 60 
transfers data from the red to the black systems 
and from the black to the red systems. In addition, 
KSP 60 verifies security labels of the various net- 
work encryption devices. 

The traffic encryption key management infor- 
mation base (TEKMIB) contains the traffic variables 
and information that define the usage of the various 
traffic keys. It is to be noted that the traffic encryp- 
tion keys are stored in a crypto unit (not shown). 



Red encrypt services module 61 is bi-direc- 
tionally connected to the KSP 60 and provides for 
the transfer of plain text data between red system 
software and KSP 60. Similarly, black decrypt ser- 
5 vices module 62 provides for the transfer of cypher 
text data between KSP 60 and black system soft- 
ware. 

As can be seen from the foregoing, the secu- 
rity kernel 6 provides combined security manage- 
io ment, key management and system security pro- 
cesses for communication between network en- 
cryption devices in a single secured data network 
system. 

The operation of the interface software of the 

75 security kernel will be illustrated through a number 
of scenarios. These scenarios perform various 
functions for the security kernel. These scenarios 
include the create cryptographic association func- 
tion. The create cryptographic association function 

20 includes subfunctions initiator create traffic encryp- 
tion key (TEK) and responder create TEK. The next 
function supported by the security kernel is the 
initiator encrypt/decrypt function. Also, local en- 
crypt and decrypt functions are provided. A secu- 

25 rity label verification function is also included. The 
next function included in the security kernel is the 
kernel initiated delete function. Further, the security 
kernel includes the red side initiated delete func- 
tion. These various scenario functions will be ex- 

30 plained in the following paragraphs. 

The create cryptographic association scenario 
creates a cryptographic association between dis- 
tributed secure computing systems. The crypto- 
graphic association includes a shared, symmetric 

35 or asymmetric information with parameters defining 
particular applications. After a cryptographic asso- 
ciation is established, the association may be used 
for cryptographic services either locally or between 
remote systems. The services include confidential- 

40 ity, integrity, authentication and nonrepeatiation. 

Security kernel 6 is connected to red process- 
ing side 7 and black processing side 8. Red sys- 
tem application management 71 is connected to 
both the kernel security management 20 and to the 

45 key management user agent (KMUA) 40. Red side 
application processes 72 are connected to the red 
system management application 71 and to the red 
security process 73. The red application processes 
72 control the operation of the red system and 

so perform various user specified functions. For a red 
side application to be allowed to transmit data, the 
red security process 73 must have a cryptographic 
association established via kernel security process 
60 to the black security process 83. Black security 

55 process 83 is connected to black application pro- 
cesses 82 and black system management applica- 
tion 81 . Data is passed between the red application 
processes 72 and the black application processes 
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82 via the red security process 73, kernel security 
process 60 and black security process 83. 

In order to establish a cryptographic associ- 
ation, which is required for the transmission of data 
between black and red processing sides, red ap- 
plication software 72 must request through red 
management application 71 that a cryptographic 
association be established. This is accomplished 
by the interconnections between red system man- 
agement application 71 and key management user 
agent 40. Similarly, the black side application soft- 
ware 82 may establish a cryptographic association 
via interface through black system management 
application 81 to KMUA 40. When the black or red 
application software or processes call the security 
kernei 6 for various functions, it is accomplished 
via the passage of parameters from the application 
processes to the security kernel. Each function 
supported by the security kernel requires different 
parameters and performs a particular security func- 
tion. These functions will be explained in the follow- 
ing paragraphs. 

The creation of a cryptographic association is 
initiated by the red processing portion 7 of the 
system shown in FIG. 3. The red system portion or 
side 7 indicates to the security kernel 6 the type of 
cryptographic association which is to be estab- 
lished, how the association will be used, algorithm 
selection and title of remote systems with which to 
establish the association. This process initiates 
communication with a remote security kernel. 

Referring to FIG. 4, a description of the initiator 
create TEK is shown. An application program of the 
red processing side initiates a request to the KMUA 
as depicted by transfer 101. The application soft- 
ware passes along to the KMUA 40 a number of 
parameters. These parameters include the title or 
name of the remote subsystem with which the 
cryptographic association is to be established. 
Next, the red side application software indicates via 
a parameter what cryptographic algorithm is to be 
selected for the data encryption and decryption. 
Further parameters passed by the application soft- 
ware to KMUA 40 include options and crypto 
modes. These modes indicate such parameters as 
one-way or two-way traffic encryption keys or other 
considerations related to a specific algorithm to be 
used. The next parameter supplied with this re- 
quest is a communication parameter including the 
identity of the network layer security, transport lay- 
er security, link layer security. For example, for 
secured data network systems, certain standard 
communication types may be specified such as: 
SP3, SP3-A, SP3-I, SP3-D, SP4 or SP4-C. Lastly, 
the red side application software indicates various 
security attributes. These security attributes may 
include the classification markings such as top 
secret, secret, or confidential or may include com- 



pany security markings such as company confiden- 
tial or company internal use only. Although the 
above security attributes are set out as examples, it 
is to be understood that the system may handle 
5 any security attributes or as many as are neces- 
sary and defined for use by the application soft- 
ware. 

Next, the KMUA 40 establishes a communica- 
tion channel with a remote system via the transfer 
io of the association request 102. The remote system 
responds to this request via transfer 103 to KMUA 
40. 

Next, negotiations may take place between the 
two systems that is, one system may have the 

75 security attributes of secret or top secret levels 
while the other system may have the security at- 
tributes of its application software as secret or 
confidential level. As a result, these two systems 
negotiate via data transfers 104 and 105 any pa- 

20 rameters such as security attributes which require 
resolution, in the above example, the secret level 
would be common to both systems and would be 
selected for the transfer of subsequent data. 

Once the two systems have set all the proper 

25 parameters, each system installs the cryptographic 
association in its red and black memory sub- 
systems. That is for the system shown in FIG. 4, 
KMUA 40 requests the establishment of the cryp- 
tographic association to the black memory side via 

30 transfer 106. This request is made through the 
black management application 81 to the black se- 
curity process 83. For completion of the test, the 
black security process 83 transmits a response to 
the black system management application 81. The 

35 response from the black memory side occurs black 
system management application 81 via transfer 
107. Similarly, KMUA 40 requests the cryptograph- 
ic association be installed on the red memory 
subsystem via transfer 108. The transfer 108 from 

40 KMUA 40 occurs via the red system management 
application 71 to the red security process 73. The 
red security process 73 responds through the red 
management application 71 to KMUA 40 via the 
101 transfer. When this cryptographic association 

45 has been established on the red side, response is 
made via transfer 101 to KMUA 40. Lastly, the 
cryptographic association has been established be- 
tween the two subsystems with the black and red 
subsystem of each system having installed the 

so association. KMUA 40 notifies the requesting red 
side application software 72 of this fact via transfer 
108 through red system management application 
71. 

Referring again to FIG. 4, the responder create 
55 TEK scenario will be explained. This scenario is 
very similar to the initiator create TEK scenario, 
except that the other system has initiated the re- 
quest for a cryptographic association. KMUA 40 
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receives the request for cryptographic association 
via transfer 103 from the black processing side. It 
responds to the initiating system via transfer 102 
through the black side. Any negotiations which 
must occur are handled via transfer 105 and 104 
between KMASE 30 and the black side. Next, 
KMUA 40 installs the cryptographic request on the 
black side via transfer 106 and receives the re- 
sponse via transfer 107. Similarly, KMUA 40 installs 
the cryptographic association on the red side via 
transfer 108 and receives the response via transfer 
101. These installations are similar to those of the 
initiator create TEK described above. The respond- 
er system is then ready to receive data from the 
initiating system. 

Referring to FIG. 5, the initiator encrypt and 
decrypt scenarios will be explained. An application 
program of the red side requests encryption of 
data by transfer 110 to the kernel security process 
60 via red security process 73. Kernel security 
process 60 performs the encryption of data re- 
ceived from the red side application software and 
transmits this encrypted data via transfer 111 to the 
black side application software via black security 
process 83 which requires the data. To accomplish 
this, the red side application software passes the 
data or a pointer to the data to the KSP 60. In 
addition, the application software indicates which 
cryptographic association is required for the data 
encryption. That is, the application software must 
indicate which of the previously established cryp- 
tographic associations requires this data. Therefore, 
the create cryptographic association, with one sys- 
tem being the initiator and one the responder, must 
have already taken place before the 
encrypt/decrypt scenario. Similarly, black side ap- 
plication software may transmit encrypted data to 
KSP 60 via the black security process 83. KSP 60 
decrypts the data from the black side application 
software and transmits the data to a red side ap- 
plication software via transfer 113 through red se- 
curity process 73. Again, it is to be noted that black 
side application software transfers certain param- 
eters to the KSP 60. These parameters include 
either the data or a pointer to the data and the 
indication of the identity of an established cryp- 
tographic association. Further, it is to be noted that 
only encrypted data exists and is handled by the 
black side application software. In contrast, either 
unencrypted data (plain text data) or encrypted 
data is handled by the red side application soft- 
ware. The encrypting and decrypting functions per- 
formed by the KSP 60 are inverse functions of one 
another. The particular cryptographic algorithm to 
use has been indicated when the cryptographic 
association was initiated to the KMUA 40. 

Referring to FIG. 6, the local encrypt and local 
decrypt scenarios will be explained. Again, for the 



local encrypt/decrypt scenarios, a prior crypto- 
graphic association must have been established. 
The local encrypt/decrypt scenarios utilized either 
symmetric or asymmetric algorithms that include 

5 confidentiality, integrity, authorization, access con- 
trol and non-repudiation. These encrypt/decrypt 
services apply only to red side application soft- 
ware. That is, the application program requesting 
the encrypt or decrypt and the program to receive 

io the encrypted or decrypted data must reside on 
the red side of the system. 

The requesting application software sends via 
red system management 71 and via transfer 118 to 
the kernel security process 60 the data to be 

75 encrypted or decrypted, the algorithm type and 
modes of operation. KSP 60 then applies the ap- 
propriate algorithm in either the encrypt or the 
decrypt direction. KSP 60 then performs the appro- 
priate algorithm in either the encrypt or decrypt 

20 mode and transmits the resultant data to the appro- 
priate red side application software 72 through red 
system management application 71 via transfer 
119. 

The next scenario to be discussed is the secu- 

25 rity label verification scenario depicted in FIG. 7. 
The processing of the security label verification is 
accomplished by the kernel security process 60. 
Security labels or tags are applied to protect in- 
formation. These labels may be verified by the 

30 kerne! security process 60 of the security kernel. 
The verification by the KSP 60 is "trusted". The 
label to be verified is sent by the red side applica- 
tion software 72 through red system management 
application 71 via transfer 120 to the kernel secu- 

35 rity process 60. 

During establishment of a cryptographic asso- 
ciation, security attributes have been set forth, as 
mentioned above. Each channel transmission be- 
tween systems or between the black and red sides 

40 of a system, has security attributes associated with 
it. These security attributes apply to data being 
transmitted, data being received and data being 
verified. That is, the security labels of the data may 
be verified upon transmission of the data, upon 

45 receipt of the data or simply at the request of one 
of the red side application programs. The required 
parameters for this scenario are the security label, 
the identity of the particular cryptographic associ- 
ation and a pointer or the data to be transmitted (or 

so a pointer to the data which was received). 

The red side application software 72 transmits 
the data along with the label to kernel security 
process 60 via red system management application 
71. Kernel security process 60 verifies the label 

55 encrypts the data according to the predefined cryp- 
tographic association and transmits the data. For 
incoming data, the kernel security process receives 
the security label and data from black system 
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management application 71 via transfer 122. KSP 
60 transmits the data to the red side application 
software. Then the KSP 60 verifies whether the 
security label is proper. For a successful verifica- 
tion by the kernel security process 60, a successful 5 
comparison indication is transmitted to the red side 
application software 72 via transfer 121 and red 
system management application 71. The red side 
application software 72 may then utilize the data. 
For an unsuccessful comparison KSP 60 transmits io 
an unsuccessful confirmation message to the red 
side application software 72 via management ap- 
plication 71 and transfer 121. The red side applica- 
tion software then ignores or zeroizes the data. 

In the third mode of operation, the red side 15 
application software may transmit the security label 
for verification purposes only via management ap- 
plication 71 and transfer 120 to KSP 60. KSP 60 
then performs the verification process as indicated 
above and returns a successful or unsuccessful 20 
comparison indication to the requesting red side 
application software 72 through management ap- 
plication 71 via transfer 121. Performing the secu- 
rity label verification within the security kernel itself 
has the advantage that the common secure pro- 25 
cess verifies the label instead of each "trusted" or 
"untrusted" red side software application program 
being required to form this verification. 

Referring to FIG. 8, the last two scenarios will 
be explained. These scenarios are the KMUA ini- 30 
tiated delete and the red side initiated delete. The 
security kernel coordinates and controls all modi- 
fication to the various established or about to be 
established cryptographic associations. These es- 
tablished cryptographic associations may required 35 
deletion. Cryptographic associations may exist for 
a particular time limit or under certain conditions. 
When the time limit of a cryptographic association 
expires or upon the occurrence of a particular 
condition, the KMUA may decide to terminate a 40 
particular cryptographic association. Upon the de- 
tection of the expiration or the happening of certain 
conditions with respect to a cryptographic associ- 
ation which require deletion, KMUA 40 first re- 
quests that the previously installed cryptographic 45 
association of the red side be deleted via transfer 
124 to red management application 71, to red 
security process, where the deletion is performed. 
When the red side security process 73 has deleted 
the cryptographic association, response is made to so 
KMUA 40 via transfer 125 through red manage- 
ment application 71. Similarly, KMUA 40 then re- 
quests that the previously installed cryptographic 
association of the black side be deleted via transfer 
126 through black application management 81 to 55 
black security process 83. When this cryptographic 
association has been deleted, response is made 
from the black side security process 83 to KMUA 



40 via transfer 127 and black management applica- 
tion 81. 

The red side may also request the deletion of a 
cryptographic association, for example, for an ex- 
piration. To accomplish this the red side application 
software 72 transmits the identity of the crypto- 
graphic association to be deleted to KMUA 40 
through red management application 71 via transfer 
125. KMUA 40 then requests the red side to delete 
the cryptographic association via transfer 124 
through red management application 71 to red se- 
curity process 73. The red side security process 
responds via transfer 125 through red management 
71 . Lastly, an acknowledgement is made to the red 
side application software 72 via the transfer 124 
through red management application 71 . It is to be 
noted that the black side may not initiate a deletion 
of a cryptographic request. 

As can be seen from the foregoing, a uniform 
set of security interfaces has been prided for 
red/black secure processing system, These ser- 
vices have been provided in a single security ker- 
nel. 

Although the preferred embodiment of the in- 
vention has been illustrated, and that form de- 
scribed in detail, it will be readily apparent to those 
skilled in the art that various modifications may be 
made therein without departing from the spirit of 
the invention or from the scope of the appended 
claims. 

Claims 

1. A security kernel (6) of a secure processing 
system for providing cryptographic, key man- 
agement and system security management 
services, said secure processing system in- 
cluding a processor (1) for the execution of 
tasks, a red subsystem (2,4) for handling plain 
text data, and a black subsystem (3,5) for 
handling cypher text data, said security kernel 
(6) comprising: 

means for security management (20) connect- 
ed to said red subsystem (21) and to said 
black subsystem (22) and to said processor 
(1), said means for security management (20) 
operating to provide for rekeying, original to 
operational seed key conversion, and deter- 
mining compromised keys; 
means for key management (40) connected to 
said means for security management (20), to 
said processor (1), and to said red and black 
(42) subsystems, said means for key manage- 
ment (40) operating in response to said means 
for security management (20) to establish 
cryptographic connection between said secure 
processing system and other secure process- 
ing systems; and 
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means for kernel security (60) connected to 
said means for key management (40), said 
means for kernel security (60) operating in 
response to said means for key management 
(40) to decrypt cypher text data of said black 5 
subsystem (62) to plain text data for use by 
said red subsystem (61) and to encrypt plain 
text data of said red subsystem (61) to cypher 
text data for use by said black subsystem (62). 

10 

2. In a secure processing system a security ker- 
nel (6) for providing cryptographic, key man- 
agement and system security management 
services, said secure processing system in- 
cluding a black processor system (8) for con- 75 
trolling encrypted data and a red processor 
system (7) for controlling unencrypted (plain 
text) data, said security kernel (6) connected 
between said red processor system (7) and 

said black processor system (8), a method for 20 
creating a cryptographic association between 
an initiator and a responder comprising the 
steps of: 

requesting (101) by said initiator the creation of 

a cryptographic association between said in- 25 

itiator and said responder; 

communicating (102) between said initiator and 

said responder to establish a secure data 

channel; 

installing (40) said cryptographic association in 30 
said black processor system (81) and in said 
red processor system (71) of said initiator and 
of said requestor; and 

notifying (108) said initiator and said responder 

of the establishment of said cryptographic as- 35 

sociation for the transmission of secure data. 

3. In a secure processing system, a security ker- 
nel (6) for providing cryptographic, key man- 
agement and system security management 40 
services, said secure processing system in- 
cluding a black processor system (8) for con- 
trolling encrypted data and a red processor 
system (7) for controlling unencrypted (plain 
text) data set, security kernel (6) being con- 45 
nected between said red processor system (7) 

and said black processor system (8), a method 
for encrypting/decrypting data transmitted be- 
tween an initiator and a responder comprising 
the steps of: 50 
establishing (40,106,108) a cryptographic asso- 
ciation between said initiator and said respond- 
er; 

requesting (118) by said initiator that encryp- 
ted data be decrypted for transmission to said 55 
responder and that plain text data be encryp- 
ted for transmission to said responder; 
passing (118) parameters from said initiator to 



said security kernel which indicate the location 
of the plain text data to be encrypted and the 
encrypted data to be decrypted; 
encrypting (60) said plain text data and de- 
crypting said encrypted data; and 
transmitting (119) said encrypted/decrypted 
data to said responder. 

4. In a secure processing system, a security ker- 
nel (6) for providing cryptographic, key man- 
agement and system security services, said 
secure processing system including a black 
processor system (8) for controlling encrypted 
data and a red processor system (7) for con- 
trolling unencrypted (plain text) data, said se- 
curity kernel connected between said red pro- 
cessor system (7) and said black processor (8) 
system, a method for verifying a security label 
of data comprising the steps of: 
establishing (40) a cryptographic association 
including a security label between an initiator 
and a responder via said security kernel; 
transmitting (122) data including a security la- 
bel by an initiator to said security kernel; 
comparing (60) said security label of said 
transmitted data with said security label estab- 
lished during said cryptographic association; 
and 

sending (121) said data with said security label 
to said responder, if said comparison of said 
security label of said cryptographic association 
and said security label of said data success- 
fully compare. 

5. In a secure processing system, a security ker- 
nel (6) for providing cryptographic, key man- 
agement and system security management 
services, said secure processing system in- 
cluding a black processor system (8) for con- 
trolling encrypted data and a red processor 
system (7) for controlling unencrypted (plain 
text) data said security kernel connected be- 
tween said red processor system (7) and said 
black processor system (8), a method for veri- 
fying a security label of data comprising the 
steps of: 

establishing (40) a cryptographic association 
including a security label via said security ker- 
nel by an initiator; 

transmitting (120) by an initiator a security 
label to said security kernel; 
comparing (60) by said security kernel said 
security label transmitted by said initiator with 
a security label created by said cryptographic 
association; and 

indicating (121) to said initiator whether said 
comparison of said security labels is success- 
ful or unsuccesful. 
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In a secure processing system, a security ker- 
nel (6) for providing cryptographic, key man- 
agement and system security management 
services, said secure processing system in- 
cluding a black processor system (8) for con- 5 
trolling encrypted data and a red processor 
system (7) for controlling unencrypted (plain 
text) data, said security kernel (6) connected 
between said red processor system (7) and 
said black processor system (8), a method for w 
deleting an established cryptographic associ- 
ation comprising the steps of: 
determining (40) a condition for which a par- 
ticular cryptographic association is to be de- 
leted; 15 
requesting (124) by said security kernel said 
red processor system to remove said estab- 
lished cryptographic association in response to 
said determination of said condition; and 
requesting (126) by said security kernel said 20 
black processor system to remove said estab- 
lished cryptographic association in response to 
said determination of said condition. 

In a secure processing system, a security ker- 25 
nel (6) for providing cryptographic, key man- 
agement and system security management 
services, said secure processing system in- 
cluding a black processor system (8) for con- 
trolling encrypted data and a red processor 30 
system (7) for controlling unencrypted (plain 
text) data, said security kernel (6) connected 
between said red processor system (7) and 
said black processor system (8), a method for 
deleting an established cryptographic associ- 35 
ation comprising the steps of: 
first requesting (125) by said red processor 
system that said security kernel delete an es- 
tablished cryptographic association; 
passing (125) by said red processor system to 40 
said security kernel an identity of the particular 
cryptographic association to be deleted; 
second requesting (124) by said security ker- 
nel that said red processor system delete said 
identified cryptographic association; and 45 
acknowledging (125) by said red processor 
system to said security kernel that said iden- 
tified cryptographic association has been de- 
leted. 

50 
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parallel subsystems, a red subsystem (7) and a black subsystem (8). The red 
subsystem (7) may communicate only with the kernel (6) since this system 
transfers plain text data. The black subsystem (8) may communicate with 
the red subsystem (7) and also other processing systems for the transmission 
of cypher text data. The security kernel (6) is a single standard interface for 
tasks associated with the red (7) and black (8) subsystems for 
communicating in a secure manner with one another and with other 
processing systems. Various security services are provided to red (7) and 

black (8) subsystem applications by a single security kernel (6). LJ 
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